In a wireless local area network (WLAN) according to the IEEE 802.11 standard, an access point (AP) in a cell coordinates packet transmission for all the stations associated with the cell. A single wireless channel, i.e., frequency band, is shared by both the uplink from the station to the AP, and the downlink from the AP to the station for data and control signals. Every station can communicate with the AP, whereas it is not required for any two stations to be within communication range of each other.
The transmission rate of the wireless channel can vary, depending on a perceived signal-to-noise ratio (SNR). For example, the physical layer of the IEEE 802.11b standard supports four rates at 1 Mbps, 2 Mbps, 5.5 Mbps and 11 Mbps.
IEEE 802.11 Acknowledgement
According to the current IEEE 802.11 standard, “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications”, Standard, IEEE, August, 1999, for wireless local area networks (WLANs), a receiver must explicitly acknowledge a correct reception of a data packet by sending an acknowledgement (ACK) message to the sender. Because the ACK message is directly associated with a previous data packet received, the ACK message has a very simple format.
IEEE 802.11e Block Acknowledgement (BlockACK)
To improve the efficiency of the wireless channel usage, IEEE 802.11e Task Group (TGe) developed a block acknowledgement technique and defines a set of new messages, IEEE 802.11e, “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Medium Access Control (MAC) Enhancements for Quality of Service (QoS)”, Draft v6, IEEE, November 2003. There, a single but more complex ACK message is used to acknowledge multiple consecutive data packets, instead of one simple ACK message for every data packet.
Therefore, the IEEE 802.11e standard uses an additional QoS control field in the MAC header. That field includes a two-bit ACK policy subfield, which specifies the type of ACK policy that is used.
A block ACK session is comprised of establishment, data transfer, BlockACK, and termination phases. Prior to the block data transfer, an Add BlockACK (ADDBA) request and an Add BlockACK (ADDBA) response are exchanged, and parameters are negotiated between two stations involved in the session. A BlockACK timeout value is specified, upon the expiry of which, the block ACK session is terminated.
Table 1 and Table 2 show the contents of the ADDBA request and response frames, respectively. For a detailed description of each field see the standard.
TABLE 1OrderInformationValue1CategorySet to 3, for BlockACK2ActionSet to 0, ADDBA request3Dialog TokenSet to a non-zero value chosenby the station4BlockACKParameter Set5BlockACK TimeoutValue
TABLE 2OrderInformationValue1CategorySet to 3, for BlockACK2ActionSet to 1, for ADDBA response3Dialog TokenCopy from the correspondingADDBA request4Status Code5BlockACK ParameterSet6BlockACK TimeoutValue
Upon the establishment of the BlockACK session, the sender can transmit blocks of data packets, separated by a short inter-frame space (SIFS) period. The session establishment is performed for a flow, which may last for thousands or even millions of packets over a time period of seconds to minutes, hours or even days.
To request an acknowledgement of an outstanding data packet, the sender transmits a BlockAckRequest message to the receiver. The BlockACK sequence control field is set to the same value as in the immediately previous BlockAckRequest message received. The BlockACK bitmap field included in the BlockACK has 128 octets and indicates the receiving status of up to 64 MAC service data units (MSDUs) or packets.
FIG. 1 shows bytes of a format 100 of a BlockACKReq message, and FIG. 2 shows bytes of a format 200 of a BlockACK message as defined in the IEEE 802.11e standard. In all figures, the numeral above the various fields indicates (I changed the figures so that numerals above the fields only indicate number of bytes) byte allocations.
The BlockACKReq message 100 includes the following fields: bit frame control 101, duration 102, receiver address (RA) 103, transmitter address (TA) 104, BlockACK Request (BAR) control 105, starting sequence control 106, and frame check sequence (FCS) 107.
FIG. 2 includes the following fields: frame control 201, duration 202, receiver address (RA) 203, transmitter address (TA) 204, BlockACK (BA) control 205, BlockACK starting sequence control 206, BlockACK bitmap 207, and frame check sequence (FCS) 208.
FIG. 3 shows bits of the BlockACKRequest (BAR) control field and BlockACK (BA) field, which have a format 300. The most significant four bits of the BAR/BA field are the TID subfield 302. The least significant twelve bits in the BAR/BA field are reserved 301.
FIG. 4 shows a format 400 of the BlockACK bitmap field in the BlockACK message. The BlockACK bitmap includes 64, two-byte-long sequence control numbers comprising fragment numbers 401, 403 and 405, each followed by sequence numbers 402, 404, and 406.
As shown in more detail in FIG. 5, each two-byte-long sequence control number 500 uniquely identifies one data packet that has been received. The sequence number field is comprised of a 12-bit-long sequence number 502 and a 4-bit long fragment number 501. The fragment number is used by fragmentation and the reassembly process.
Limitations of Current BlockACK
In any network, bandwidth is an important resource. For a high throughput WLAN according to the IEEE 802.11n standard, the MAC protocol must achieve a 70-80% efficiency to meet the design requirement of 100 Mbps at the MAC service access point (SAP). Therefore, the current MAC protocol must be improved.
However, the per frame ACK mechanism according to the current IEEE 802.11 standard presents a potential source of huge waste of the wireless channel. This is the exact reason why BlockACK is proposed in the IEEE 802.11e standard. Unfortunately, the BlockACK mechanism itself is not entirely optimized with respect to the bandwidth efficiency.
The BlockACK bitmap field in the BlockACK frame has a fixed length of 128 bytes. Thus, for any number of data packets transmitted as a block using the BlockACK, the 128-byte-long BlockACK bitmap must be included in the BlockACK. This causes significant waste and inflexibility for small blocks.
Moreover, the current BlockACK message has the constraint that the acknowledgement must be for data belonging to the same traffic class (TC) or traffic stream (TS). Currently, the transmission opportunity (TXOP) obtained by contention (ECCA-TXOP) or allocated by polling (HCCA-TXOP) is always associated with a particular TC or TS, and only the data packets of that TC or TS can be transmitted during the TXOP.
Therefore, a better block acknowledgement method is desired.